Internet Info 1993

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1993 / Internet Info CD-ROM (Walnut Creek) (1993).iso / inet / ien / ien-153 < prev next >

Wrap

Text File | 1988-12-01 | 24.6 KB | 767 lines

INDRA Working Paper INDRA Note 959 TSIG 4.0 IEN 153 29th July 1980 Realization of the Yellow Book Transport Service Above TCP C. J. Bennett ABSTRACT: This note defines an enhancement of the service provided by the US DoD Standard Transmission Control Protocol (TCP) sufficient to meet the requirements of the UK Network Independent Transport Service (the Yellow Book). 1. Introduction This document defines a means of providing the Yellow Book Transport Service [1] above the DARPA Internet facilities, in particular TCP [2], so that this can then be used to support other services such as endpoint file transfer without requiring UK hosts to implement the Internet family of protocols. It assumes familiarity with both TCP and the Yellow Book. The basic approach taken is to enhance the TCP service along the lines suggested for enhancing X25 in Annex I of the Yellow Book, taking into account the different services provided by TCP. In addition, the note discusses how to integrate Yellow Book TCP so that it can run alongside ordinary TCP - an issue the Yellow Book ignores for Yellow Book X25. 2. Deficiencies of TCP A comparison of the services provided by TCP and those provided by the Yellow Book reveals that TCP is unable to support directly, either in whole or in part, the following Yellow Book features: (i) The RESET and ADDRESS primitives. (ii) The Yellow Book multiple-domain addressing structure. The TCP address space constitutes a single naming domain in Yellow Book terms. Consequently, features involving addressing - notably ACCEPT - are inadequately supported by TCP. (iii) Much of the subsidiary information provided with Yellow Book primitives. The fact that the source address provided with certain actions such as DISCONNECT is not provided is again a limitation of the global TCP naming domain. The Yellow Book 'Explanatory Text' parameters have no corresponding feature in TCP. (iv) The closest equivalent to Yellow Book EXPEDITED data - theoretically requiring a priority data channel - is TCP URGENT data. However, TCP URGENT data remains in sequence, and the URGENT pointer only marks the end of the data. Its beginning is not delimited. (v) The Yellow Book DISCONNECT is a full-duplex close, whereas the TCP CLOSE is only half- duplex. The TCP RESET is a unilateral close, used in error conditions. Connection closure Bennett 1 INDRA 959 provides particularly subtle problems. Hence in order to provide a Yellow Book service above TCP an enhancement of TCP is necessary. The remainder of this document discusses such an enhancement. 3. Principles of the Enhancement The basic principles of the enhancement are as follows: (i) Where a TCP function corresponds directly to a Yellow Book function that TCP function is used directly. (ii) Where the Yellow Book function requires more information or action, the TCP function is associated with a TCP Control Message in a defined way. This message is a TCP letter of defined format containing the information required. (iii) Where there is no TCP function even remotely corresponding to the required Yellow Book function, a control message is defined which may be used by the source and destination processes if possible, and may be forwarded into other transport domains more capable of taking the appropriate action. 4. The Yellow Book TCP Enhancement 4.1 Distinguishing the Yellow Book TCP There are several ways a TCP connection providing a Yellow Book service could be distinguished from a normal TCP connection. These are as follows: (i) A single TCP port could be reserved for Yellow Book service. Additional multiplexing could then be provided using the lines proposed in Annex III of the Yellow Book. (ii) A number of TCP ports could be reserved for the different higher level services required, each one of which would be defined as including the enhancement defined within this document. Bennett 2 INDRA 959 Yellow Book above TCP (iii) A TCP option could be defined which when associated with a SYN would denote the 'enhanced TCP service' option - i.e. the data stream would be governed by this document. The first of these possibilities leads to unnecessary duplication of multiplexing facilities - perfectly adequate multiplexing is already done within the TCP. The second is potentially restrictive in that it limits the growth of future services, and would probably eventually lead to the informal adoption of the first solution. This notes supports the third course, subject to approval by the DARPA Internet Group. Proposed text defining the TCP option, using the format of the TCP specification, is as follows: Enhanced TCP Service +--------+ |00000010| +--------+ Kind = 2 This option specifies that the TCP connection is providing the data formats and command messages necessary to support the enhanced services offered by the UK standard Network Independent Transport Service. This option may only be specified in the header of a packet which has the SYN bit set to 1. If the receiving process is unable to support this option, the connection should be aborted via a RESET. The adoption of this option does not imply that a TCP itself is required to understand the structures of this document. It does allow such TCPs to be built. For TCPs which do not support these structures directly, the option is effectively a null option, whose presence should be indicated to the receiving process. Failing the adoption of this facility, the first choice (of a single reserved port) is supported here. 4.2 Identification of TCP Command Messages Once the connection is identified as providing a Yellow Book TCP service, the next problem is how to identify TCP Command Messages within the data stream. The X25 enhancement made use of the X25 Q-bit for this Bennett 3 INDRA 959 Yellow Book above TCP purpose, but there is no corresponding function within TCP. The choices are as follows: (i) Provision of a TCP Q-bit facility. This is unlikely to occur, not least because the example of XXX shows that it is liable to misuse. (ii) Further definition of the 'Enhanced Service' option, so that the occurrence of this option with a letter specifies that the letter is a Command Message. (iii) Structuring the data stream itself. Despite the marginally greater data efficiency of the second choice, the last choice is supported here, as it requires no modification of the TCP user interface. It does, however, require the transmission of a data octet which will require a fairly clever user interface if extensive buffer copying is to be avoided. The structure proposed is as illustrated in Figure 1. Each TCP letter is prefaced by a single octet, known as the TYPE octet. This takes a value of 0 for data letters and a value of 1 for command messages. All other values are undefined. +------+----- - - - - - ------+ | TYPE | LETTER BODY | +------+----- - - - - - ------+ | | / | | 0 = DATA |-------< | 1 = COMMAND \ Figure 1: Letter Structure in Yellow Book TCP 4.3 Structure of TCP Command Messages A TCP Command Message is a Yellow Book TCP Letter of TYPE 1. Bennett 4 INDRA 959 Yellow Book above TCP The first octet of the message defines the COMMAND CODE of the message. These codes are defined in subsequent sections, and have been chosen to correspond to the command codes of the X25 Command Messages. Following the command code is a number of PARAMETERS. The significance of these parameters is defined by their position in the parameter sequence for each command; thus no intermediate parameter may be omitted, though it may have a null value. Parameters, however, may be omitted if they and all succeeding parameters have null values. Most parameters have a free field format. For this reason each parameter is constructed of a number of FRAGMENTS. These fragments consist of a header byte and the body of the fragment, which may have a maximum length of 127 octets. The fragment header is a single octet. The high-order bit of this octet, if set to 1, declares that the current fragment is the last fragment of the current parameter. The remaining seven bits define the length in octets of the current fragment. Bennett 5 INDRA 959 Yellow Book above TCP This structure is summarised in Figure 2. +-------- - - - - - - - - --------+ | COMMAND MESSAGE | +-------- - - - - - - - - --------+ / \ / \ / \ +------+-------- - - + - - - - - + - - -------+ | CODE | PARAM 1 | ....... | PARAM N | Command +------+-------- - - + - - - - - + - - -------+ Structure / \ / \ / \ / \ +-------- - - + - - - - - + - - --------+ | FRAG 1 | ....... | FRAG K | Parameter +-------- - - + - - - - - + - - --------+ Structure | \ | \ | \ | \ +--------+------ - - - - - -------+ | HEADER | BODY | Fragment Structure +--------+------ - - - - - -------+ | \ | \ | \ +-+-+-+-+-+-+-+-+ | | C O U N T | Header Structure +-+-+-+-+-+-+-+-+ | |--- EOP Bit Figure 2: TCP Command Message Structure A parameter with a null value is represented by a fragment header whose EOP bit is set to 1 and whose count field is set to 0. The rules governing the syntax of free-field parameters are the same as those defined in section 2.7 of the Yellow Book, based on the use of the IA5 character set. The sole difference between this structure and the X25 Command Message structure is that the count field in the fragment header is extended by one bit - this bit is used for a specific purpose in X25 CONNECT messages which does not arise with the TCP. This doubles the maximum fragment size. Because of the similarity of structure the same terminology has been used, though the term 'fragment' is somewhat Bennett 6 INDRA 959 Yellow Book above TCP unfortunate in the DARPA context through its specific association with the Internet Datagram Protocol. 4.4 Yellow Book Commands and TCP The following general remarks apply to the following specification: (i) All codes are specified as decimal integers. (ii) All address fields include the appropriate TCP address components, specified as /<NET ID>+<INTERNET HOST ID>+<PORT NO>/, where the bracketed fields are the character strings of the octal representations of those TCP fields, except where otherwise noted. Thus, the NIFTP port (octal 10651) at ISIE (net 12, host 1, logical host 0, IMP 64) will be denoted by the string: /12+200064+10651/ 4.4.1 CONNECT The CONNECT command message is defined by the following code and parameters: Code = 16 Parameter 1: Called Address Parameter 2: Calling Address Parameter 3: Quality of Service Parameter 4: Explanatory Text This message will be preceded by the usual TCP three-way handshake. Where possible or appropriate, the quality of service parameter will be used to select TCP quality of service from the options defined in the TCP specification. The CONNECT message will be the first message sent by the calling party. It will be possible for the calling party to initiate the transfer of data before the arrival of an ACCEPT message. 4.4.2 ACCEPT The ACCEPT command message is defined by the Bennett 7 INDRA 959 Yellow Book above TCP following code and parameters: Code = 17 Parameter 1: Recall Address Parameter 2: Quality of Service Parameter 3: Explanatory Text This message will be the first message sent by the called party after the three-way handshake, unless the call request was rejected (see DISCONNECT, below). If the recall address and the quality of service do not differ from those specified in the CONNECT, the ACCEPT will normally consist of the code octet only. 4.4.3 DISCONNECT The DISCONNECT command message is defined by the following code and parameters: Code = 18 Parameter 1: Reason Parameter 2: Address of DISCONNECT Initiator Parameter 3: Explanatory Text The reason parameter is a single octet giving a machine-oriented encoding of the reason the DISCONNECT was initiated. The defined reasons are listed in Appendix B of the body of the Yellow Book. Parameter 2 is included to cover the case where the DISCONNECT was initiated by some intermediate gateway (where 'gateway' is used in the Yellow Book sense). DISCONNECT will always cause the TCP to issue an URGENT call. On receipt of a DISCONNECT message, no further data may be sent and all data currently queued for transmission should be flushed if possible. No data will be passed across to the user after a DISCONNECT has been issued. Beyond this, the exact DISCONNECT sequence used varies depending on the state of the connection, as follows: (i) If the DISCONNECT is being used to reject a CONNECT request, the DISCONNECT message will be followed by a TCP RESET. This will abort the TCP connection, flushing all outstanding data. No response is expected. The URGENT pointer points to the TCP RESET. Bennett 8 INDRA 959 Yellow Book above TCP (ii) In the normal case of closing an open connection, the DISCONNECT issued by the initiator will be followed by a TCP FIN. The remote party will respond with an optional DISCONNECT message accompanied by a FINACK and a FIN. The URGENT pointer points to the TCP FIN. (iii) For error terminations, a DISCONNECT message should be answered with a TCP RESET. The issuer of the DISCONNECT will also issue a TCP RESET after a timeout period, if a RESET has not already been received. The URGENT pointer points to the end of the DISCONNECT message. 4.4.4 DATA DATA is sent as a sequence of Yellow Book TCP data letters, as defined above. 4.4.5 PUSH The PUSH function is conveyed by use of the TCP EOL function, pointing to the data octet at which the PUSH was issued. 4.4.6 EXPEDITED The EXPEDITED command message is defined by the following code and parameter: Code = 21 Parameter 1: EXPEDITED data EXPEDITED data is accompanied by a TCP URGENT pointer pointing to the end of the letter. It should be noted that this will cause the receiver of the URGENT to process all data up to the URGENT pointer in 'fast' mode, whether EXPEDITED or not. As noted above, TCP has no direct equivalent of a priority data channel, but the mechanism described allows the preservation of EXPEDITED data so that it may be passed as such in subsequent networks. Bennett 9 INDRA 959 Yellow Book above TCP 4.4.7 RESET The RESET command message is defined by the following code and parameters: Code = 19 Parameter 1: Reason Parameter 2: Address of RESET Initiator Parameter 3: Explanatory Text TCP has no equivalent of the RESET function (a TCP RESET is something else entirely). Thus the only TCP action taken with a RESET message is to accompany it with an URGENT pointer pointing to the end of the RESET message. As with DISCONNECT, the defined RESET reasons are those listed in Appendix B of the main portion of the Yellow Book. The address parameter is again included to cater for the case where a RESET was initiated in some intermediate network. A RESET may only be issued if the connection is fully open and there are no RESETs already outstanding. A RESET message must always be replied to with another RESET message, leaving the connection open, or with an error DISCONNECT message followed by a TCP RESET, which will abort the connection. All data and control messages, with the exception of DISCONNECT, received after a RESET has been issued and before a RESET reply has been received, will be discarded without informing the user. In the case of DISCONNECT, the connection will be considered as having closed in an abnormal state. If a DISCONNECT has been issued, a received RESET will be ignored. Where possible the issue of a RESET should cause the sender to flush its transmission buffers. 4.4.8 ADDRESS The ADDRESS command message is defined by the following code and parameters: Code = 20 Parameter 1: Address Parameter 2: Address Qualifier Bennett 10 INDRA 959 Yellow Book above TCP The ADDRESS qualifier is a single octet parameter taking one of the values defined in the Yellow Book: 0: The message is passing towards the addressed object. 1: The message is passing away from the addressed object. 2: An addressing error has been detected. There is no associated TCP action taken with an ADDRESS message. The receiver of an ADDRESS message will perform the appropriate ADDRESS transformation as defined in the Yellow Book. It is recommended that the ADDRESS function should not be used. 5. Conclusions One of the difficulties of writing a note such as this is that it is addressed to several audiences with different interests and not necessarily a great deal of overlap either in aim or in background. The immediate audience is the team at University College London who are involved in implementing a 'Protocol Convertor' to make possible direct access between hosts in Britain using the CCITT and UK national standards and the hosts in the US based on the DARPA Internet standards. For this audience, the document hopefully defines an answer to what will soon be a practical need, though it is a matter for continuing debate to what extent the full enhancement defined here will be implemented. Within Britain, the wider audience aimed at is centred on the Transport Service Implementors' Group. For this group, the aim of the document will be well understood - it is defining a service enhancement similar to the one that is already defined for X25 and the ones they are defining for their local campus networks. The aim is to provide a common transport service for all these systems. They will be unfamiliar with the detailed nature of the TCP itself, but this is not particularly important. The major interest of the document lies in the fact that the system being Bennett 11 INDRA 959 Yellow Book above TCP enhanced is not an ordinary local network, but an entire family of networks, and the resultant enhancement will make possible direct authorised access between UK and US hosts. I would also like to point out the issue of separating Yellow Book enhancements from ordinary uses of a network service. This issue is not addressed by the X25 enhancement specification. The US Internetwork Group is likewise unfamiliar with the concepts and details of the Yellow Book Transport Service. For them, the document will be of interest in that it shows how to coordinate two very different approaches to internetworking. The Catenet, based on TCP, can be described as a strongly connected internetwork system, with common transport protocols and a common address space. The UK Transport Service takes an approach based on providing a common service interface, which leads to a weakly connected system with common service protocols and no common address space. Within this approach, the entire Internet system appears as a single component network, as delimited by the TCP and its address space. Beyond this the document proposes a new TCP option. For most existing TCPs this option will effectively be a null option which must be signalled to the user at call setup time. However, there is no reason why a TCP could not be built which contained the features of this note as optional enhancements selectable by choosing the option. 6. References [1] - PSS User Forum Study Group Three: "A Network Independent Transport Service" SG3/CP(80)2. February 1980. [2] - Information Sciences Institute: "Transmission Control Protocol" IEN 112. August 1979. Bennett 12 INDRA 959